Teamprojekt Softwareentwicklung

Erinnerung: Spezifikationsdokument

  • (Erste) Abgabe Ende nächster Woche

  • Details und Bewertungskriterien im Moodle verlinkt

  • Lasst das Dokument auch euren AGs zukommen und holt Feedback ein

  • (Zweite) Abgabe zum 1. Dezember

Softwareentwicklungsprozesse

  • Iterationen

  • Anforderungen

  • Qualitätssicherung

Iteration

  • 2-wöchiger Planungsprozess

  • Treffen mit AG

  • Anforderungen verwalten

  • Software entwickeln

  • Qualitätssicherung

  • Laufende Software liefern

Treffen mit AG

  • Abnahme von implementierten Anforderungen

    • Oft live Demo + abnicken

  • Definition von weiteren Anforderungen

  • Priorisierung von Anforderungen für die nächste Iteration

Treffen mit Gruppe

  • Reflexion/Anpassung der Anforderungen

    • Zu groß? Schlechte Schätzung? Zu unklar?

    • Anpassungen mit AG absprechen

  • Aufgabenverteilung

  • Planung des AG treffen

  • Reflexion was gut funktioniert, was besser funktionieren könnte

Protokolle

  • Vor dem Treffen festlegen, wer Protokolliert.

  • Notiert wichtiges:

    • Neue Anforderungen

    • Was ist dem AG wichtig

    • Absprachen/Entscheidungen

    • Punkte die auf später verschoben wurden

Anforderungen

(siehe auch W04 Anforderungen)

Anforderungen

  • „Vertrag zwischen AG und Gruppe“

  • Werden vom Team erstellt, vom AG abgenommen

    • Das ganze Team sammelt Anforderungen

    • Keine Trennung zwischen

      • „Entwickler:innen“ und

      • „Menschen die Anforderungen sammeln“.

  • Basieren auf Input vom AG, von eventuellen Nutzern, oder eigeninitiativ.

  • Kleinteilig genug, damit mehrere pro Iteration bearbeitet werden können

  • Mehrwert für die Projektziele

  • Achtet auch auf nicht-funktionale Anforderungen!

    • Sicherheitsstandards

    • Laufzeitumgebung

Anforderungsmanagement

  • Anforderungen müssen dokumentiert sein

    • User Stories

    • Issues

    • Tasks

    • Cards

    • Prototypen/Mockups

  • Nutzt Formate die mit euren Werkzeugen funktionieren!

Struktur von Anforderungen

  • Unbearbeitet:

    • Deskriptor

    • prüfbare Akzeptanzkriterien

    • Aufwandsschätzung

  • Erledigt:

    • in Iteration X

    • Aufwand in Stunden pro Teammitglied

    • Von AG abgenommen

Beispiel 2

Anforderung 101: Nutzersymbole

  • Akzeptanzkriterium: Die Spieler werden auf der UI mit farblich unterscheidbaren Symbolen dargestellt.

  • Geschätzer Aufwand: 1 Punkt.

  • Tatsächlicher Zeitaufwand: (noch offen)

Story Points

  • Abstrakte Aufwandsschätzung

  • Punkte:

    • 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ∞\infty, ☕, ?

  • Relativ zu anderen Anforderungen

Pointing Poker

Velocity

  • Im Nachhinein

  • Wie viele Stunden pro Story Point?

  • (Wie viele Story Points pro Iteration?)

Iterationszyklus

  • Neue Version der Software

    • Erfüllte Akzeptanzkriterien?

    • Velocity der erfüllten Anforderungen?

    • Gesamtstorypoints in dieser Iteration?

  • Neue Anforderungen?

  • Änderung an existierenden Anforderungen?

  • Prioritäten für existierende Anforderungen?

  • Welche Anforderungen werden in dieser Iteration bearbeitet?

    • Arbeitet wichtige einfache Anforderungen zuerst ab

Qualitätssicherung

(siehe auch W04 Qualitätssicherung)

Auftraggeber*in: Ich möchte eine Fitnessanwendung entwickeln lassen mit der Benutzer*innen ihren Fortschritt speichern und planen können (als Anzahl absolvierter Trainings, gestemmtem Gewicht, gelaufener Zeit etc.).

Noch keine QS Ziele

Ziele identifizieren

Es soll verschiedene Ansichten auf die Daten geben, da wir Nutzer*innen haben, die unterschiedlich viel Details sehen wollen.

Vermutlich ist Datensicherheit wichtig, muss aber konkretisiert werden.

Wir haben Anfänger*innen und Expert*innen in der Zielgruppe. Sie sollen sich alle damit zurechtfinden können.

Benutzbarkeit

Nach dem BP will ich vielleicht ein weiteres Praktikum ausschreiben, in dem die Anwendung noch weiterentwickelt wird.

Wartbarkeit

QS Maßnahmen

Wartbarkeit:

Wir beschränken uns darauf, die Lesbarkeit des Quellcodes und zugehöriger Kommentare sicherzustellen. Hierbei folgen wir dem […] Style Guide, welcher […]. Außerdem stellen wir die Erweiterbarkeit der Anwendung bzgl. Datenansichten sicher, da hier schon jetzt Erweiterungen abzusehen sind. Um die Lesbarkeit zu gewährleisten, führen wir statische Code Analysen durch. Hierzu setzen wird folgendes Tool ein […].

Qualitätssicherung

  • Ziele

    • mit dem AG koordiniert

    • klar beschrieben

    • überprüfbar

    • erreichbar

  • Maßnahmen

    • Was wird getan?

    • Wer führt die Maßnahme durch?

    • Wann wird die Maßnahme ausgeführt?

    • Welche Konsequenzen werden nach der Durchführung ergriffen?

QS Planung

  • Überlegung: Welche Ziele sind sinnvoll für das Projekt? Abstimmung mit AG

  • Konkretisierung und Abgrenzung der Ziele

  • Überlegung: Wie wird der QS-Prozess am besten in den Entwicklungsprozess integriert?

  • Recherche: Welche Tools können die QS unterstützen?

  • Festlegen: Wie werden die Belege der QS Durchführung am besten gesammelt?

QS Kategorien

  • Datensicherheit

  • Zuverlässigkeit

  • Portabilität

  • Wartbarkeit

  • Effizienz

  • Benutzbarkeit

  • Funktionalität

  • Kompatibilität

Vorgegebene QS Ziele & Maßnahmen

  • Wartbarkeit, Zuverlässigkeit

  • Code Reviews, Tests, Pair Programming

  • Weitere nach Wunsch der AGs

    • Macht nicht zu viel!

Code Reviews

  • Reviewer hat code nicht geschrieben.

  • Jeder code wird gereviewt.

    • Wann? (z.B. vor Akzeptanz)

    • Checkliste.

Pair & Group Programming

  • Dient der Wissensweitergabe

  • Konzept: Arbeiten mit kurzen Kommunikationswegen

  • Arbeitet gemeinsam im gleichen Raum (auch virtuell!)

  • Klassisch: Eine steuert, beide Denken

  • Auch möglich:

    • Alle arbeiten an verschiedenen Dingen.

    • Bei aufkommenden Fragen werden dynamisch Gruppen gebildet.

Tests

  • Manuell

    • Checklisten!

    • Prüfbarkeit!

  • Automatisch

    • Unit

    • Integration

    • Continuos Integration

  • Wie ist der Prozess bei Testfehlern?

Fragen?